In a cloud computing environment, computing is delivered as a service rather than a product, whereby shared resources, software and information are provided to computers and other devices as a metered service over a network, such as the Internet. In such an environment, computation, software, data access and storage services are provided to users that do not require knowledge of the physical location and configuration of the system that delivers the services.
In a virtualized computer environment, such as may be implemented in a physical cloud computing node of the cloud computing environment, the virtualized computer environment includes a virtual operating system. The virtual operating system includes a common base portion and separate user portions that all run on a physical computer. The physical computer is referred to as a host. The common base portion may be referred to as a hypervisor and each user portion may be called a guest. Each guest is a logical partition of the physical resources of the computer. A guest operating system runs on each guest, and the guest appears to the guest operating system as a real computer. Each guest operating system may host one or more virtual machines.
An administrator of the cloud computing environment may build a reusable pattern which defines the topology and application environment used to service the customer (i.e., the user receiving the services provided by the cloud computing environment) as well as satisfies the customer requirements, such as application and processing requirements. The pattern is an abstract model of the topology and application environment that encapsulates the installation, configuration and management of middleware and applications, such as the middleware and applications that run on the virtual machines in the physical cloud computing nodes. Such a pattern can be deployed repeatedly thereby avoiding the need to provision these environments individually and manually.
Currently, such a pattern is built using only the software components that are accessible from external repositories from the same vendor. Patterns cannot currently be built using software components from separate external repositories from different vendors. As a result, it becomes more difficult to build a pattern that satisfies the customer's requirements. Furthermore, since patterns can only be built using software components stored in external repositories from the same vendor, there is not currently a means for deriving relationships between various software components from different vendors.